Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update gNMI specification to clarify Set error handling. #157

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

robshakir
Copy link
Contributor

  * (M) rpc/gnmi/gnmi-specification.md
    - remove references to the deprecated `error` field in the
      `SetResponse` and `UpdateResult` messages, explicitly
      specifying the error handling behaviour follows the standard
      gRPC error model.

Fixes #62.

  * (M) rpc/gnmi/gnmi-specification.md
    - remove references to the deprecated `error` field in the
      `SetResponse` and `UpdateResult` messages, explicitly
      specifying the error handling behaviour follows the standard
      gRPC error model.
Copy link
Contributor

@wenovus wenovus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@wenovus wenovus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dplore noted here that there is ambiguity as to what to return when multiple error codes are valid: #155 (comment)

@dplore
Copy link
Member

dplore commented Jul 8, 2022

In the case of multiple errors, I believe we should specify "the implementation SHOULD return the first error encountered"

As a newcomer to gRPC, I found it useful to directly reference the standard gRPC return codes and this gRPC core doc page on status codes

indicate that the encoding is not supported.
* When the client specifies a payload utilising an encoding that is not
supported by the target (e.g., JSON) - `Unimplemented (12)` SHOULD be used to
indicate that the encoding is not supported.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* When the client specifies a value which is not permitted by the target - `Unimplemented (12)`
SHOULD be used. For example, setting an interface full_duplex leaf to false when the interface
only supports full_duplex.

Copy link
Member

@dplore dplore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider comments on

  • additional use case for unimplemented (12) and In the case of multiple errors
  • I believe we should specify "the implementation SHOULD return the first error encountered"

As a newcomer to gRPC, I found it useful to directly reference the standard gRPC return codes and this gRPC core doc page on status codes

I found these more straightforward to read than the referenced gRPC error handling guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

errors in SetResponse (proto vs. spec)
3 participants